fix(ci): trigger release PR auto-merge via workflow_run instead of pull_request - #479
Merged
sebastiancorrea81 merged 1 commit intoAug 7, 2026
Merged
Conversation
…ll_request The release-please PR is always opened by github-actions[bot], whose author_association on this repo is CONTRIBUTOR rather than MEMBER/COLLABORATOR. That's enough to make GitHub treat its pull_request-triggered runs as needing manual approval (the same gate used for outside-collaborator forks), even though the branch lives in this repo. Evidence: every recent release PR (6.8.0, 6.8.1, 6.8.2, 6.7.1, 6.7.2) was merged by a human, and the last two auto-merge-release-pr runs on the release PR completed with action_required and zero jobs. workflow_run runs use the workflow file from the default branch with full permissions and aren't subject to that gate, and it also naturally waits for the whole "Release Please" run (release-please + the generate-readmes follow-up commit) to finish before firing, so the concurrency/cancel workaround for the follow-up commit race is no longer needed either. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sebastiancorrea81
deleted the
fix/auto-merge-release-workflow-run-trigger
branch
August 7, 2026 16:20
3 tasks
sebastiancorrea81
added a commit
that referenced
this pull request
Aug 7, 2026
## Problem Follow-up to #479. Confirmed live right after #479 merged: the new `find-pr` job ran and correctly located PR #476, but skipped it with "Open PR doesn't match expected author/label", leaving the release PR un-merged. Root cause: `gh pr list --json author` is GraphQL-backed and represents `github-actions[bot]` as `"app/github-actions"`, not `"github-actions[bot]"`. The comparison in `find-pr` (and the reusable workflow's `release_pr_author` default, and the old `pull_request`-triggered version's `github.event.pull_request.user.login`) all expect the REST-style `"github-actions[bot]"`. ## Fix Switch the PR lookup from `gh pr list --json author` to `gh api repos/{repo}/pulls?state=open&head={owner}:release-please--branches--main` (REST), whose `user.login` is `"github-actions[bot]"` as expected. Verified locally against the real PR #476 before pushing. ## Test plan - [ ] Merge this PR. - [ ] Confirm in Actions that the next `auto-merge-release-pr` (workflow_run) run resolves `pr_number` for PR #476 and actually merges it this time. - [ ] Confirm the tag/GitHub Release gets published without human intervention. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
sebastiancorrea81
added a commit
that referenced
this pull request
Aug 7, 2026
🤖 I have created a release *beep* *boop* --- ## [6.10.0](v6.9.0...v6.10.0) (2026-08-07) ### Features * **service_definition:** forward link spec fields from the template ([#477](#477)) ([2994e6b](2994e6b)) ### Bug Fixes * **ci:** compare release PR author against REST-style bot login ([4e00860](4e00860)) * **ci:** compare release PR author against REST-style bot login ([#481](#481)) ([75a16ea](75a16ea)) * **ci:** trigger release PR auto-merge via workflow_run instead of pull_request ([e7eff48](e7eff48)) * **ci:** trigger release PR auto-merge via workflow_run instead of pull_request ([#479](#479)) ([80738de](80738de)) * **eks:** support an optional aws_profile for the kubernetes provider exec plugin ([#471](#471)) ([ccb2f5f](ccb2f5f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
This was referenced Aug 7, 2026
sebastiancorrea81
added a commit
that referenced
this pull request
Aug 7, 2026
Small, low-risk change used as a real trigger to test the full post-merge automation chain (#479, #481, nullplatform/actions-nullplatform#89) end-to-end on a clean cycle: this PR's merge → release-please PR → auto-merge (workflow_run + REST author check + --admin) → tag/release, with no manual step in between. Root README's usage example pinned `infrastructure/aws/vpc` to `v1.56.1`, several major versions behind the current `v6.10.0` — updated so copy-pasting the example doesn't point at a stale tag. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
auto-merge-release-pr(triggered onpull_request) has been silently broken for a while: the release-please PR is always opened bygithub-actions[bot], whoseauthor_associationon this repo isCONTRIBUTOR(notMEMBER/COLLABORATOR). That's enough for GitHub's "require approval for outside collaborators" gate to treat itspull_request-triggered runs as needing manual approval — the same mechanism used for fork PRs — even though this branch (release-please--branches--main) lives in this repo, not a fork.Evidence:
auto-merge-release-prruns on PR chore(main): release 6.10.0 #476 (release 6.9.0) completed with conclusionaction_requiredand zero jobs executed.queuedfor >21h and never ran.Fix
Switch the trigger from
pull_requesttoworkflow_run(on"Release Please"completing). Runs triggered byworkflow_runalways use the workflow file from the default branch with full permissions and aren't subject to the outside-collaborator approval gate.Since
workflow_rundoesn't carry PR context, a newfind-prjob resolves the open release PR itself (same lookupgenerate-readmesalready does inrelease.yml) and validates its author/label before merging — this is exactly what the reusable workflow's existingpr_numberinput was already built for (see its description innullplatform/actions-nullplatform), so no changes needed there.This also removes the
concurrency/cancel-in-progressworkaround for thegenerate-readmesfollow-up commit race —workflow_runonly fires once the entire "Release Please" run (both jobs) has finished, so there's nothing to race against anymore.Test plan
main.auto-merge-release-prnow fires viaworkflow_run,find-prresolves the release PR, andautomergecompletes successfully (noaction_required/queued).🤖 Generated with Claude Code